Thanks for this patch, @fluidnumerics-joe; but it doesn't seem to work (yet). I've updated the runtime of the tests/test_advection.py.py:test_nemo_curvilinear_fieldset unit test so that it reaches the antemeridian; and it (still) throws an error. Do you know what's going on? Does this updated unit test help you isolate the issue?

Note that the error thrown before was at lon=180.2 which is larger than grid.lon.max=180, but having fixed this still leads to an error:

FAILED tests/test_advection.py::test_nemo_curvilinear_fieldset - parcels._core.statuscodes.GridSearchingError: Grid searching failed at (z=[0.], lat=[79.6822], lon=[179.7905])

The core assumption, noted in the comment of the changes, is that the particle position is less than 180, to match the way you were implementing periodic boundary conditions in the associated issue.

What is the assumed range of particle longitudes going forward in parcels?

This patch fixes the original issue reported where the particle longitude is -177.4

What is the assumed range of particle longitudes going forward in parcels?

@erikvansebille and I were discussing what the assumed range should be in parcels, and although (-180,180) seems logical to me, we also considered allowing particles to have any lon, which could be mapped to the same location using a modulo.

Although the patch is able to find the particle at lat=88, lon=-177.4, it still is not able to find a particle at lat=79.6822, lon=179.7905, which falls within np.max(fieldset.U.grid.lon) = np.float64(179.99891662597656).

Copy that. I'll get something more robust in place

What is the assumed range of particle longitudes going forward in parcels?

@erikvansebille and I were discussing what the assumed range should be in parcels, and although (-180,180) seems logical to me, we also considered allowing particles to have any lon, which could be mapped to the same location using a modulo.

Just a note, the ERA5 data when downloaded straight from CMS is in the range [0,360).

I'd vote for lon$\in \mathbb{R}$ and lat$\in [-90,90]$ if possible.

Thanks @fluidnumerics-joe, for fixing this bug! I just committed e24c631, which extends the unit test for curvilinear grids to much longer runtime (and thus multiple loops); this also required a small bugfix to the interpolator which makes it more robust now